[Critical] R1-1: The v9 hello gate rejects any current-protocol host.hello that omits permissions.camera, but the two existing Host-hello fakes in packages/cli were not updated — so npm test --workspace=packages/cli is red on this head with 11 net-new failures. Source: [test]

Both fakes (src/serve/routes/live.test.ts:62-66, src/serve/server.test.ts:41808-41812) send protocolVersion: LIVE_HOST_PROTOCOL_VERSION (now 9) with permissions: { microphone, accessibility, screenRecording } and no camera, so legacyHelloWithoutCamera is false, parseHello returns undefined, the socket closes 1002 and the coordinator stays at blocker: 'host_missing'. Measured: routes/live.test.ts 4 failures (GET /live/status returns 'host_missing' instead of 'appshot'; POST /live/start 503 instead of 200; POST /live/shortcut 409 instead of 200, and 409 instead of 500 for the persist-failure case) and server.test.ts 7 failures. Neither file is in this diff, so a path-based judgment would have waved them through as pre-existing.

Witness — test-delta against a built merge base, not a path guess:

netNew = [src/serve/routes/live.test.ts, src/serve/server.test.ts]
base 70cf36339: 14 failures (settings 13 + AppContainer 1), neither live file
PR head:        25 failures = the same 14 + 11 new
npm test --workspace="packages/cli" -> exit 1

Deterministic, so CI's VITEST_RETRY: 2 will not absorb it; GitHub already reports Test (ubuntu-latest, Node 22.x) as failing.

Suggested fix: add camera: 'granted' to the permissions object in both fakes, matching readyHello in live-host-coordinator.test.ts:94. Do not relax parseHello.

The fix must not violate live-host-coordinator.test.ts:576 — it('rejects a v9 Host hello that omits camera readiness', …) asserts closeCode === 1002 and blocker: 'host_missing', and :558 asserts a protocolVersion: 7 hello without camera closes 4006 with blocker: 'host_version'. The missing-camera rejection at protocol 9 is intended behaviour, so the fakes change, not the gate.

Please pin the fix with a mutation: after updating the fakes, remove camera: 'granted' again and confirm those 11 tests go red — that is the acceptance criterion for this finding.

— qwen3.8-max via Qwen Code /review (v0.23.0)

[Critical] R1-31: [fails-closed] [new-surface] Adding com.apple.security.device.camera as a fourth macOS entitlement breaks the repo's own pinned least-privilege guard, and Live Host (macos-latest) is red because of it. Source: [review]

.github/workflows/live-host.yml — which this PR does not touch — asserts the opposite on two counts. assert_live_host_entitlements (:113-140) builds expected = [allow-jit, allow-unsigned-executable-memory, device.audio-input] and fails on actual.length !== expected.length || actual.some((key, index) => key !== expected[index]), then runs against both build/entitlements.mac.plist (:140) and the packaged entitlements (:144) — so a fourth key fails on length alone. Separately, :105-107 iterates for unused_permission in NSBluetoothAlwaysUsageDescription NSBluetoothPeripheralUsageDescription NSCameraUsageDescription and errors Packaged app declares unused permission $unused_permission, while camera capture needs that Info.plist key. This is the blocker the triage gate raised on this PR; re-checked against the code at 3f0a30c2, it still stands.

Witness, at the reviewed commit:

entitlements.mac.plist -> 4 keys: cs.allow-jit, cs.allow-unsigned-executable-memory,
                                  device.audio-input, device.camera
live-host.yml:120-123  -> const expected = [ ...3 keys... ]
live-host.yml:127-128  -> actual.length !== expected.length || actual.some(...)
gh pr checks 11369     -> Live Host (macos-latest)  fail  58s

Suggested fix: settle the permission surface with a maintainer, then move the guard in the same change — add com.apple.security.device.camera to the expected array at its matching index, drop NSCameraUsageDescription from the unused-permission list at :105, and add a positive assertion that the packaged Info.plist declares it with a real usage string. If camera capture is not meant to ship in the packaged desktop app, gate it out of that build instead of widening the entitlement set. Widening a sandboxed app's macOS permission surface is a product/security decision, not something a review can settle from the diff.

The assertion at :127-129 is ordered and exact-length, so a new key must be inserted at the matching index rather than appended anywhere.

Please pin the fix with a mutation: after Live Host (macos-latest) goes green, add an unrelated fifth entitlement and confirm assert_live_host_entitlements still fails.

— qwen3.8-max via Qwen Code /review (v0.23.0)

[Critical] R1-2: [certifies-falsely] [new-surface] requestQuit() latches intentionalClose = true and stops discovery on entry, but the rejection handler restores only quitPromise — so a failed quit on the shared-daemon socket path leaves the Host permanently unable to report a disconnect or reconnect, while still publishing a ready snapshot. Source: [probe]

On the shared-daemon path welcome.daemonShutdownV1 is absent, so shutdownTarget is undefined and quitConnection takes the socket.send(host.action stop) branch. When that fails — buffer saturated so canSendHostControlMessage throws (:322-330), the socket tearing down before the send callback, or the 75 s QUIT_TIMEOUT_MS — the handler clears quitPromise and rethrows, but intentionalClose stays true and discovery stays stopped. socket.on('error') (:885, || this.intentionalClose) and socket.on('close') (:897, if (this.intentionalClose) return;) then both short-circuit, so when the daemon actually goes away the Host publishes no disconnected snapshot and never calls scheduleReconnect(). daemon.start() runs exactly once at boot (index.ts:2456), and only connect() (:621) writes intentionalClose = false — unreachable, because quitState = 'failed' latches off activateNativeServices (:1199) and failRequiredDaemonMessage (:976), the one path that calls forceReconnectNow(). The overlay keeps rendering a live-looking call while every subsequent utterance is dropped.

Witness, intact PR vs the flip:

INTACT: intentionalClose after failure = true / socket still held = true
        snapshots published after the daemon died = []
        getSnapshot() still reports = {"phase":"ready",..."state":"listening"}
        handshakes 1 -> 1 after a new discovery record
FLIP  : intentionalClose after failure = false
        snapshots published after the daemon died =
          [{"phase":"disconnected","error":"daemon_disconnected"},{"phase":"connecting"},...]

The flip also shows the fix needs both halves — with intentionalClose alone repaired, handshakes stayed at 1 because discovery.stop() is never undone, so scheduleReconnect only redials the stale currentRecord.

Suggested fix: in the rejection handler, restore the pre-quit state scoped so the authenticated-target latch is untouched — if (!this.quitTarget) { this.intentionalClose = false; this.discovery.start(); if (this.socket) this.armHeartbeat(this.heartbeatIntervalMs); }. If restoring the live session is not wanted, the minimum is to publish a terminal snapshot so the UI stops claiming ready.

The restore must stay inside if (!this.quitTarget): quit-connection.test.ts — it('retries the same authenticated target after cleanup failure and disconnect', …) asserts value.handshakes() === 1 and that every retry carries the original x-qwen-live-nonce, so clearing the latch on the quitTarget path would open a second WebSocket to a different instance and break it.

Please pin the fix with a mutation: add a case to quit-connection.test.ts using fixture({ standalone: false }) that fails the stop frame, then after assert.rejects(requestQuit()) closes the peer and asserts value.snapshots gains a 'disconnected' entry and value.handshakes() === 2; removing the restore must turn it red.

— qwen3.8-max via Qwen Code /review (v0.23.0)

[Critical] R1-3: [fails-closed] [new-surface] Every /live/quit failure — including "the daemon is no longer there to answer" — collapses into one unconfirmed-quit rejection, and quitTarget is never cleared, so the Host app can never be quit and never reconnects again. Source: [probe]

quitConnection's fetch (:290-297) has no try/catch and never inspects error.cause.code, and the rejection handler takes no parameter, so the cause is discarded and only quitPromise is cleared. quitTarget has exactly two occurrences in the file — the declaration at :224 and the write at :265 — and nothing ever clears it, so every later requestQuit() re-selects the same dead target and fails identically. After one failed Quit against a daemon that has since exited, quitHost() never reaches quitApproved = true; app.quit() (index.ts:690-691), before-quit preventDefault()s without quitApproved (:2245-2250), the tray Quit (:2211) and the IPC route (:1504) both re-enter quitHost, daemon.stop() (:2255) sits after the quitApproved gate, and activateNativeServices (:1199) refuses forever once quitState !== undefined. The Electron app becomes a zombie with no UI path to exit short of kill -9. The diagnostic cannot distinguish causes either: index.ts:684 logs only error.name.

Witness, intact PR vs the flip:

INTACT: attempt 1 rejected key = ..."host.error.quitUnconfirmed"... error.cause = undefined
        quitTarget latched = {"url":"http://127.0.0.1:38925",..."instanceNonce":"authenticated_instance_01"}
        attempt 2 (daemon gone) outcome = rejected / error.name = Error / error.cause = undefined
        /live/quit attempts = 1   <-- attempt 2 never reached a server
        attempt 3 outcome = rejected
FLIP  : quitTarget latched = undefined / attempt 2 = resolved / attempt 3 = resolved

Suggested fix: wrap the fetch and classify the failure. When no HTTP response was ever received and the cause is connection-level ((error.cause as NodeJS.ErrnoException)?.code in ECONNREFUSED / ECONNRESET / ENOTFOUND, or a 404/410 from /live/quit), the daemon the user asked to stop is already gone — clear this.quitTarget and resolve, or reject with a distinct host.error.quitDaemonGone that quitHost treats as exit-approved. Keep the sticky target and the quitUnconfirmed rejection for every case where a response was received but did not confirm. Carry the cause into the diagnostic instead of error.name.

The classification must key on "no response received", not on "requestQuit failed": quit-connection.test.ts:214-247 requires that a received 500 response keeps quitTarget sticky — assert.equal(attempts, 2), both requests carrying the original x-qwen-live-nonce, and assert.equal(value.handshakes(), 1) after reconnectNow()/forceReconnectNow().

Please pin the fix with a mutation: welcome with daemonShutdownV1, close the fixture HTTP server so the recorded port refuses, call requestQuit() (asserts it rejects), then call it again and assert it resolves with requests.length === 0; removing the classification makes the second call take the HTTP path again and reject.

— qwen3.8-max via Qwen Code /review (v0.23.0)

[Critical] R1-4: [certifies-falsely] [new-surface] requestQuit() reports success without ever attempting the shutdown, because the HTTP-only /live/quit path is gated on a WebSocket being OPEN while shutdownTarget is wiped by every disconnect — orphaning the standalone daemon. Source: [probe]

quitConnection's target branch (:284-311) never touches socket; it needs only target.url, target.token and target.instanceNonce. Yet :264 considers shutdownTarget only when socket is truthy, and socket is non-undefined only when welcomed && snapshot.phase === 'ready' && readyState === OPEN (:257-262). shutdownTarget is cleared at :600 (connect), :893 (socket.on('close')), :1030 (closeSocket) and :1053 (terminateSocket), so inside any reconnect window target is undefined, quitConnection(undefined, undefined) falls through to if (!socket) return; (:319) and the promise resolves — index.ts:690-691 sets quitApproved = true and calls app.quit(). Windows that all clear shutdownTarget before the next welcome: reconnectNow() (:347-353, fired by index.ts:701 2.5 s after every readiness change), forceReconnectNow() (:356-362, reachable from an audio-transport failure while the user stares at an error overlay and clicks Quit), the armHeartbeat 4008 close (:1083, 15 s at the default interval), and scheduleReconnect after the daemon's own 4008. Qwen Live then appears to quit while the qwen-live daemon keeps running indefinitely — packages/qwen-live/src/index.ts:113-124 exits only on SIGINT/SIGTERM or a confirmed /live/quit — holding the port, the discovery file, the session log, and the Proactive monitors and background agents this PR adds, with no UI attached. This contradicts the suite's own stated intent, "does not report a timed-out shutdown as success": here success is reported with no attempt at all.

Witness — the deciding line is the request count:

INTACT: shutdownTarget while ready = { url:'http://127.0.0.1:35153', ..., token:'quit-token' }
        after forceReconnectNow: shutdownTarget = undefined  socket.readyState = 0 (CONNECTING)
        requestQuit outcome = resolved   /live/quit requests = 0
FLIP  : after forceReconnectNow: shutdownTarget = { ... }
        requestQuit outcome = resolved   /live/quit requests = 1

Suggested fix: key the authenticated shutdown target to the instance it was verified against rather than to the live socket. Store shutdownTarget at welcome together with record.instanceNonce (already nonce-verified at :684-694), stop clearing it in socket.on('close') / terminateSocket / connect, and clear it only when handleDiscovery installs a record with a different instanceNonce. Then select it as this.quitTarget ?? (this.shutdownTarget?.instanceNonce === this.currentRecord?.instanceNonce ? this.shutdownTarget : undefined), independent of socket, passing socket through only for the fallback stop action.

The retained target must still come only from a nonce-verified welcome, never from currentRecord alone: quit-connection.test.ts:137-147 ('closes only Host when there is no authenticated connection') asserts assert.equal(wrongInstance.requests.length, 0) for a welcome whose daemonInstanceNonce does not match the discovery record, and for a connection that was never started.

Please pin the fix with a mutation: welcome with daemonShutdownV1, then value.peer.close(1001, …) (or forceReconnectNow()) so the host is inside the reconnect window, then await connection.requestQuit() and assert value.requests[0].url === '/live/quit' carrying the original nonce; with the socket gate in place the request list stays empty.

— qwen3.8-max via Qwen Code /review (v0.23.0)

[Suggestion] R1-23 (2 of 5 locations): the six new tools' argument names are declared twice — once in these JSON-schema properties blocks and once in the hand-listed allowlist inside parseProactiveArguments (orchestrator/live-session.ts:186-212) — with nothing tying the two copies together, and the allowlist (not additionalProperties: false, which the provider may not enforce) is the gate that actually runs. See location 1 of 5 (subagents/types.ts:101) for the pattern, the witness and the general fix. Source: [probe]

Failure scenario: 26 argument names (target_title, target_title_contains, title, modalities, condition, trigger_response, narration_focus, narration_style, repeat, duration_sec, reminder_text, …) are duplicated verbatim across two files in this same PR. The first field added to a schema here without the matching allowlist entry makes a schema-valid model call fail at runtime with `Unknown Proactive argument${…}: ${unknown.join(', ')}.` (live-session.ts:214), which surfaces to the user as a failed voice round trip; the mirror mistake (allowlist entry without a schema property) advertises nothing to the model while silently accepting the key.

Witness (sweep over the real population — schema keys imported from the real LIVE_SESSION_TOOLS/PROACTIVE_SESSION_TOOLS, allowlist literals parsed out of the real live-session.ts, both directions):

create_proactive_monitor: SCHEMA_ONLY=[] ALLOW_ONLY=[]
create_live_narration   : SCHEMA_ONLY=[] ALLOW_ONLY=[]
create_proactive_timer  : SCHEMA_ONLY=[] ALLOW_ONLY=[]
update_proactive_task   : SCHEMA_ONLY=[] ALLOW_ONLY=[]  (11 names, identical both sides)
cancel_proactive_task   : SCHEMA_ONLY=[] ALLOW_ONLY=[]
TOTAL gated schema properties swept: 26; tools with divergence: 0

0 divergence today — and grep for allowlist|Unknown Proactive argument|parseProactiveArguments across *.test.ts finds no test cross-checking schema against allowlist, so 0 tests pinning it either.

Suggested fix: derive the allowlist from the authoritative declarations instead of restating them — look the tool up in PROACTIVE_SESSION_TOOLS by function.name and build the set from Object.keys(tool.function.parameters.properties ?? {}).

The current chain ends in an empty allowlist for any tool name that is not one of the six (: [], live-session.ts:211), and LIST_PROACTIVE_TASKS_TOOL declares properties: {} (definitions.ts:441-444) — the derivation must keep rejecting all keys for the list tool and for unknown names.

Please pin the fix with a mutation: a case in orchestrator/live-session.test.ts asserting each PROACTIVE_SESSION_TOOLS member's declared property names are all accepted by the proactive dispatch path, and that a name outside the six still rejects every key; replacing the derivation with a stale hand-list must turn it red.

— qwen3.8-max via Qwen Code /review (v0.23.0)

[Suggestion] R1-23 (3 of 5 locations): the wire PCM rates are written as fresh literals instead of referencing this module's own exported QWEN_REALTIME_INPUT_SAMPLE_RATE (:27) and QWEN_REALTIME_OUTPUT_SAMPLE_RATE (:28) — which a repo-wide grep shows nothing reads. See location 1 of 5 (subagents/types.ts:101) for the pattern, the witness and the general fix. Source: [probe]

Failure scenario: the 24 kHz output contract now lives in three unlinked places — the exported constant at :28 (read by nobody), this new wire declaration at :2217, and the playback side's private const OUTPUT_SAMPLE_RATE = 24_000; in packages/live-host/src/preload/audio-engine.ts:17. The constants are the module's declared contract for the provider's PCM rate, so a maintainer who changes one (or adds a model whose output rate differs) updates the constant and the host, leaves this declaration behind, and the provider keeps sending 24 kHz while the host resamples by a different number — pitch-shifted or garbled playback with no compile error, because the pinning test hardcodes the literals too (realtime-session.test.ts:264-267 asserts sample_rate: 16000/24000).

Witness: repo-wide grep across all of packages/ finds no read sites for either exported name — only the declarations at :27-28 plus a duplicate pair at packages/cli/src/serve/live/qwen-realtime-session.ts:15-16.

Suggested fix: use sample_rate: QWEN_REALTIME_INPUT_SAMPLE_RATE / QWEN_REALTIME_OUTPUT_SAMPLE_RATE here so the exported constants become the single in-package source for what is declared on the wire, and have packages/live-host/src/preload/audio-engine.ts and proactive/scheduler.ts bind to them rather than to private copies.

realtime-session.test.ts:264-267 currently pins input: { format: { type: 'pcm', sample_rate: 16000 } }, output: { format: { type: 'pcm', sample_rate: 24000 } } — the substitution must keep those exact values on the wire.

Please pin the fix with a mutation: extend the existing model-gate test (:236-268) to assert settings['audio'].output.format.sample_rate === QWEN_REALTIME_OUTPUT_SAMPLE_RATE (imported) rather than the literal 24000; restoring the literal plus a changed constant then goes red.

— qwen3.8-max via Qwen Code /review (v0.23.0)

[Suggestion] R1-23 (4 of 5 locations): the PCM16 bytes→seconds conversion is hard-coded as 16_000 * 2 twice in this file (poll() at :602-604 for the audioSeconds diagnostic, hasWarmEvidence() at :636-638 for the gate) instead of using the exported input-rate constant from the module this file already imports QWEN_REALTIME_LIMITS from. See location 1 of 5 (subagents/types.ts:101) for the pattern, the witness and the general fix. Source: [probe]

Failure scenario: the two copies must agree with each other and with the rate the realtime session actually negotiates. QWEN_REALTIME_INPUT_SAMPLE_RATE = 16_000 is exported at realtime/realtime-session.ts:27 and the session pins input: { format: { type: 'pcm', sample_rate: 16_000 } } at :2216. If that rate is ever changed in one place, audio.minEvalDurationSec silently keeps measuring against 16 kHz: at a 24 kHz input the gate would request evaluations after only ⅔ of the configured audio duration, and the audioSeconds value logged by proactive.evaluation_gate would disagree with the number the gate actually used — the diagnostic that exists to explain a stuck task would point the wrong way. The duplication is also within a single file, so the two sites can drift independently of any rate change.

Witness: grep across all of packages/ finds no read site for QWEN_REALTIME_INPUT_SAMPLE_RATE; the two (16_000 * 2) literals are at scheduler.ts:604 and :638.

Suggested fix: import QWEN_REALTIME_INPUT_SAMPLE_RATE in the existing import from ../realtime/realtime-session.js and add one private helper used by both sites — private audioSeconds(state: MediaEvidence): number { return state.audio.reduce((total, input) => total + input.bytes, 0) / (QWEN_REALTIME_INPUT_SAMPLE_RATE * 2); }.

export const QWEN_REALTIME_INPUT_SAMPLE_RATE = 16_000; (realtime-session.ts:27) — input is 16 kHz while output is 24 kHz per QWEN_REALTIME_OUTPUT_SAMPLE_RATE on the next line, so the helper must bind to the input constant, not a shared one.

A constant substitution and de-duplication adds no guard or branch to pin (N/A) — the existing audio-window tests (scheduler.test.ts:749, :777) must stay green.

— qwen3.8-max via Qwen Code /review (v0.23.0)

[Suggestion] R1-23 (5 of 5 locations): the 100 000-character instruction bound is a bare literal duplicated at two new sites in this file (:630 and here) and a third time in the caller, which derives a budget from it across a package boundary with no shared symbol. See location 1 of 5 (subagents/types.ts:101) for the pattern, the witness and the general fix. Source: [probe]

Failure scenario: orchestrator/live-session.ts:1019-1024 computes the memory prompt budget as 100_000 - buildLiveInstructions(...).length - MEMORY_SYSTEM_PROMPT.length - 1_000, and instructions() (:984-997) re-derives the base text at publish time from the current context.visualInput while the budget was fixed at attach time. The two numbers are coupled only by convention: if this file's bound is lowered, or the base instructions grow past the 1 000-char slack, configure() throws a RangeError out of publishMemoryInstructions (live-session.ts:1006-1012), which has no try/catch, so it escapes syncMemorySettings() into the settings route instead of degrading — and no compiler or test links the three copies.

Witness: the 100_000 literal appears at realtime-session.ts:627, :1963 and live-session.ts:1019; measured base instructions are 9,301 chars and MEMORY_SYSTEM_PROMPT 697 chars, so the slack is real but unenforced.

Suggested fix: export one MAX_REALTIME_INSTRUCTIONS_CHARS = 100_000 from this module, use it at :627 and :1963, and have attachMemory's budget subtract that imported constant instead of its own literal.

MemorySession enforces promptBlocks().length <= maxPromptChars (memory/session.ts:169) using the value attachMemory computed — so the exported constant must be the one both sides read, or the enforcement and the guard keep two different numbers.

A constant extraction adds no branch to pin (N/A); if the caller's budget is switched to the imported constant, live-session.test.ts's memory-attachment cases are the ones that would go red on a divergence.

— qwen3.8-max via Qwen Code /review (v0.23.0)

[Suggestion] R1-29: update_proactive_task's description tells the model it may omit the title selector for any adjacent reference to the just-created task, but the dispatcher accepts a selector-less update only when the single argument is repeat: true — and the failure receipt handed back does not name the rule that was broken, so the retry is a guess rather than a repair. Source: [probe]

The description reads "…Omit the selector only for an immediately adjacent reference to the just-created task. Never use update for a new request.", while live-session.ts:1700-1704 throws ProactiveArgumentsError('An adjacent selector-less update may only set repeat=true.') unless Object.keys(args).length === 1 && args['repeat'] === true. Trigger: the user creates a monitor, then says "call it Kitchen timer instead". The model follows the description and calls update_proactive_task({"title":"Kitchen timer"}) — schema-valid (minProperties: 1, no required, title declared) and past the allowlist (live-session.ts:186-212) — so it reaches the guard and is rejected. The cost is larger than an extra round trip: renderFailureFact (proactive/tool-receipt.ts:426-443) maps invalid_arguments to one generic sentence and discards receipt.error, and live-session.ts:1816-1819 returns only renderProactiveToolReceipt(receipt), so the model is told "did not pass validation" with no indication that adding target_title fixes it. Because continuesResponse: true (definitions.ts:348) registers a continuation at realtime-session.ts:1888-1893, the model gets another response and re-issues a guess — a spoken stumble on a call the tool surface explicitly endorsed. The repair path does not cover this: detectProactiveRepairIntent (proactive/tool-repair.ts:29-45) tests only PROACTIVE_PROMISE / PROACTIVE_CANCEL_CLAIM against the assistant's transcript, never an argument-shape rejection.

Witness — the receipt carries the rule, the model never sees it:

PROBE receipt.committed = false
PROBE receipt.failure_code = invalid_arguments
PROBE receipt.error = "An adjacent selector-less update may only set repeat=true."
PROBE what the model is handed = "提醒任务未创建或修改，提交的信息未通过校验。"
PROBE does the rendered receipt name the rule it broke? NO
PROBE does the rendered receipt tell it to add a selector? NO

Suggested fix: state the enforced rule in the description — '…Omit the selector only to set repeat=true on the just-created task; every other change needs target_title or target_title_contains.' Separately, and more valuable, let renderFailureFact pass receipt.error through for invalid_arguments so the continuation can repair instead of guessing. Relaxing the handler instead is possible, but then the guard at live-session.ts:1701 and its test must change together.

The rule the wording must match is if (Object.keys(args).length !== 1 || args['repeat'] !== true) → 'An adjacent selector-less update may only set repeat=true.' (live-session.ts:1701-1703), and the sibling cancel path is stricter still — 'An adjacent selector-less cancel must have no arguments.' (:1763-1767) — so the two descriptions cannot share one blanket "omit the selector" sentence. The design doc does record the restriction itself ("For safety, an implicit update can only change repeat from false to true"), so the rule stays; only its advertisement is wrong.

Please pin the fix with a mutation: for the receipt half, a case in proactive/tool-receipt.test.ts (or orchestrator/live-session.test.ts) asserting that an invalid_arguments receipt whose error names the rule renders that rule back to the model — removing the pass-through makes it red. The description half is text only (N/A); if the author instead relaxes the handler, the witness is a case asserting a selector-less {title: …} update commits against the adjacent task.

— qwen3.8-max via Qwen Code /review (v0.23.0)